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Abstract 

After a year of testing and demonstrating a Cisco mobile 
access router intended for terrestrial use onboard the low- 
Earth-orbiting UK-DMC satellite as part of a larger merged 
ground/space IP-based internetwork, we reflect on and 
discuss the benefits and drawbacks of integration and 
standards reuse for small satellite missions. Benefits include 
ease of operation and the ability to leverage existing systems 
and infrastructure designed for general use, as well as reuse 
of existing, known, and well-understood security and 
operational models. Drawbacks include cases where 
integration work was needed to bridge the gaps in 
assumptions between different systems, and where 
performance considerations outweighed the benefits of reuse 
of pre-existing file transfer protocols. We find similarities 
with the terrestrial IP networks whose technologies we have 
adopted — and also some significant differences in 
operational models and assumptions that must be considered. 

Introduction 

On 27 September 2003, a Cisco Systems mobile access 
router was launched into low Earth orbit as a secondary 


experimental payload onboard the UK-DMC disaster 
monitoring constellation satellite built by Surrey Satellite 
Technology Ltd. (SSTL). The UK-DMC satellite’s primary 
mission is to provide Landsat-style, mid-resolution, remote 
sensing imagery. This satellite operates within the Disaster 
Monitoring Constellation (DMC) of small satellites built by 
SSTL for a number of collaborating countries. 

That Cisco router was able to be integrated into the UK- 
DMC satellite because of engineering study work done 
previously that had adopted the Internet Protocol, IP, for 
communication with onboard network stacks, and which had 
built the ground station network around a Cisco router and 
standard serial interfaces using HDLC (ref. 1). 

The onboard router was tested as part of a wider 
internetworking experiment involving a wide range of 
organizations across civil, commercial and defense sectors. 
In June 2004, after lying dormant while the satellite’s 
primary payloads were commissioned and used, the router 
was used as the IP-compliant, space-based asset that was 
evaluated as part of the evaluation of the OSD Rapid 
Acquisition Initiative Net Centricity (RAI-NC) “Virtual 
Mission Operations Center” (VMOC) demonstration that 
took place at Vandenberg Air Force Base (ref. 2). 
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Cisco Router in Low Earth Orbit 


The Cisco router in Low Earth Orbit (CLEO) deployed 
onboard the UK-DMC satellite consists of two PC- 1 04/Plus- 
based circuit boards: the PowerPC-based Cisco 3251 Mobile 
Access Router (MAR) processor card, and a four-port serial 
mobile interface card (SMIC). 

Although this mobile access router is capable of 
supporting 100 Mbps Fast Ethernet connections, there is no 
Ethernet onboard the UK-DMC satellite, and 8.1 Mbps serial 
interfaces are used to connect to other payloads (ref. 3). The 
onboard serial links are designed to match the use of an 
8.1 Mbps serial interface on a Cisco 2621 router receiving 
the output of the downlink from the modem in each ground 
station; the downlink is extended to each payload as required. 

The router cards flown (fig. 1) received some hardware 
modifications for the space environment: 

1. The cards were flow-soldered with lead-based, rather 
than tin-based, solder. Although tin is environmentally 
friendlier than lead, tin solder is particularly prone to 
growing “whiskers” in a vacuum, leading to shorted circuits. 

2. All terrestrial plastic connectors which would warp in 
temperature extremes were removed and replaced with 
point-to-point soldered wiring. Unused components around 
those connectors were removed. 

3. A large heatsink was attached to the main processor, 
and a brace conducted heat away to the payload’s aluminum 
chassis. 

4. Wet electrolytic capacitors with vents that would leak in 
a vacuum were replaced with dry capacitors. 

5. The clock battery was removed to avoid explosion and 
leakage; the router was later configured in orbit to use 
Network Time Protocol (NTP) in order to automatically 
learn the correct time from a ground-based server whenever 
it is powered up. 

The cards were mounted on an SSTL-designed 
“motherboard” that provided connectivity and power control. 
The completed assembly took up half a payload tray. The 
router assembly successfully survived full system flight-level 
qualification testing (vibration, vacuum and thermal cycling) 
on its first attempt. This included a temperature range of 
-60 to 35 °C and a vacuum of less than 1 x 1 0 ’Pa. 

Total power consumption of the combined unit is 
approximately 10 W at 5 V. The router cards flown were not 
modified in any way to provide increased radiation tolerance, 
and did not use space-qualified parts. The router software 
was also unmodified — a commercial release of Cisco’s IOS 
Internetworking Operating System software (12.2(1 1)YQ of 
September 2002) was flown. This use of commercially- 
available hardware and software is unrestricted by ITAR 
regulations. 



Figure 1. — CLEO assembly mounted in rack tray. At back 
left: router card with heatsink brace in place. At front left: 
serial card is connected to payloads via half-width 
motherboard under cards. 

Access to configure CLEO on orbit via internetworked 
ground stations has been via the console serial port, telnet, 
secure shell (ssh), and secured web interfaces. As an 
experimental payload added to the UK-DMC satellite, the 
router is not connected directly to the satellite downlink. 
Instead, when testing the router during a ten-minute pass 
over a ground station, the onboard computers form a virtual 
star topology centered on the router, and frames are passed 
from the router to an onboard computer to be copied out to 
the downlink. 

While being tested during satellite passes over 
groundstations, CLEO has operated as expected on orbit, 
both in power draw and performance. Although CLEO is far 
less power-hungry than traditional 19 in. rack-mounted 
routers, the 10 W the assembly draws, combined with the 
10 W taken by the 8 Mbps S-band downlink when that is 
operational, forms a significant proportion of the UK-DMC 
satellite’s 30 W power budget. CLEO is powered off when 
not being tested in order to conserve available satellite power 
and battery life. 

UK-DMC Imagery and Networking 

The DMC small satellite constellation, within which the 
UK-DMC satellite operates, is a co-coordinated collection of 
ground and space assets owned by multiple organizations 
(ref. 4). Each of the sun-synchronous-orbiting DMC 
satellites, including the UK-DMC satellite, carries an optical 
imaging payload developed by SSTL to provide a minimum 
of 32 m ground resolution with a uniquely wide swath width 
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of over 640 km. (Some DMC satellites provide better 
resolutions.) All payloads use green, red and near-infrared 
bands equivalent to Landsat TM+ bands 2, 3 and 4. 

Images are stored onboard the UK-DMC in two PowerPC- 
based computers designed by SSTL, with 1 and 0.5 gigabytes 
of RAM respectively. These are the Solid-State Data 
Recorders (SSDRs). During passes over groundstations, 
images are copied as files to the SSTL mission operations 
center or partner groundstations via an 8.1 Mbps S-band 
downlink. 8.1 Mbps was chosen as it is the maximum rate 
supported by the serial interface on the Cisco routers to be 
used in the ground stations; this is also the rate at which the 
onboard router communicates via its serial links. There is 
also a low-rate 38.4 kbps downlink to provide satellite status 
telemetry when the high-rate downlink is not active, while 
commands are received via a low-rate uplink at 9600 bps. 

All links carry IP packets inside frame relay and HDLC 
encapsulation. This protocol encapsulation is an engineering 
choice made as a result of experience gained previously 
testing IP use with SSTL’s UoSAT-12 satellite (ref. 1). 

Payloads are given dedicated access to the downlink 
according to an uploaded schedule, and must flood the 
downlink with packets to transfer as much data as possible in 
the limited time available during a pass. Image transfer from 
satellite to ground station uses a custom rate-based UDP- 
based fde transfer protocol designed and implemented by 
SSTL (ref. 5). This protocol gives smaller code footprint size 
and increased performance when compared to SSTL’s earlier 
implementation of the CCSDS File Delivery Protocol 
(CFDP), allowing more image data to be transferred during a 
pass, so that the entire contents of an SSDR’s memory can be 
downloaded, and the SSDR can then be turned off until its 
next use, in order to save power. 

The UK-DMC on-board computer (OBC) that controls the 
platform provided telemetry about the status of the satellite 
as a UDP broadcast stream from its IP stack. 

The ground stations belonging to SSTL and to the partner 
countries owning other satellites in the Disaster Monitoring 
Consortium are networked together using IP. PCs on each 
ground station Ethernet local area networks (LANs) run 
applications for dealing with satellite telemetry and images. 

The SSTL Mission Planning System 

To provide command and control across the disaster 
monitoring constellation, SSTL developed a secure 
distributed Mission Planning System (MPS) with distributed 
systems interfaces and a web-based end user interface. It is 
the responsibility of this MPS to: 

1. Receive and collate image requests for areas of interest. 

2. Perform orbit propagation. 


3. Prioritize and schedule acquisition opportunities based 
on request priorities and asset constraints. 

4. Automatically generate spacecraft and ground station 
command schedules to execute the image acquisition plan. 

Use of each country’s spacecraft and ground station in the 
DMC is planned through an independent MPS that holds its 
master schedule. Each MPS can communicate with its peers 
over the public IP Internet, via standard web services (the 
SOAP Simple Object Access Protocol), through secure 
encrypted tunnels (SSL secure sockets layer) and using a 
Virtual Private Network (VPN). With little modification, that 
web services interface was used to negotiate unplanned 
programmed image requests received in real-time from the 
General Dynamics VMOC software used during 
internetwork tests, using well-understood network standards: 
XML-RPC (remote procedure calls) and SOAP. The VMOC 
was allocated an appropriate priority so as not to interrupt 
commercial imaging. This live interaction between 
distributed planning systems was demonstrated successfully, 
with the UK-DMC MPS executing and delivering on VMOC 
image requests during and after testing and demonstrations at 
Vandenberg. 

Testing CLEO With VMOC 

The Cisco router in Low Earth Orbit (CLEO) project, 
funded by Cisco Systems, and the VMOC project, funded by 
the RAI-NC program, are separate but complementary in 
their shared use of the Internet Protocol, and the overlapping 
organizational groups involved in these projects gain mutual 
benefit from working together, as they are already 
compatible technically thanks to their shared use of common 
open standards. The VMOC and router testing was a 
collaborative experiment centered on the Air Force, the 
Army and NASA Glenn Research Center, and involving 
other organizations (ref. 6). NASA Glenn worked with Cisco 
to test the CLEO router under a mutually beneficial Space 
Act agreement. 

The Army and Air Force Space Battle Labs provided 
support and performed the overall metrics collection 
and evaluation as part of the OSD-sponsored VMOC effort. 
The VMOC demonstrations occurred “in the field” during 
1 to 13 June 2004, followed by a three-day demonstration 
during 14 to 16 June. Operators at the Vandenberg 
demonstration specified areas of the Earth, received satellite 
images and telemetry, and commanded the router. 

Field users relied on mobile routing to communicate across 
the Internet via a home agent at NASA Glenn’s headquarters 
in Cleveland, Ohio, to the Cisco router onboard the satellite 
via the supporting SSTL ground station (fig. 2). The 
addressing for SSTL’s existing ground station network 
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Figure 2. — Network topology for the Vandenberg demonstration. 


design is flat, with all ground stations numbered similarly, 
and addresses are translated to the outside world if necessary; 
support for mobile networking had to be added without 
disrupting either SSTL’s existing network operations or the 
primary imaging mission. 

Use of mobile routing provided CLEO with a static IP 
address that the VMOC could use to command the 
spaceborne router, entirely independent of the ground station 
currently visible to the satellite. CLEO can currently be 
accessed either via SSTL’s own ground station in Guildford, 
England, or via the Universal Space Network ground station 
in Poker Flat, Alaska, which replicates the SSTL ground 
station and modem use. 

Both the CLEO router and the IP-based VMOC software 
application were able to build upon SSTL’s adoption of IP 
and the IP-based infrastructure of the satellites and ground 
stations that was being built, and so could treat the satellites 
as nodes on a large IP -based network that seamlessly merged 
space and ground assets. The capabilities demonstrated here 
are evolutionary and desirable outcomes emerging from all 
parties adopting use of the Internet Protocol and being able to 
collaborate fully technically as a result; not as a result of any 
careful top-down long-term planning. 


Other Networking Demonstrations 

Further demonstrations of CLEO and VMOC have been 
held. 

On 5 November 2004, VMOC/MPS imaging request 
operations, using the SSTL ground station to task the UK- 
DMC satellite, were demonstrated at Air Force Space 
Command Fleadquarters in Colorado Springs. 

On 18 November 2004, further demonstrations took place 
to the leadership of Air Force Space Command during its 
Commanders’ Conference in Los Angeles, CA. On 2 
December 2004, the Joint VMOC team performed a similar 
demonstration to leadership from the Air Staff and Joint Staff 
in the Washington, DC area. 

On 10 May 2005, a public demonstration of CLEO and 
VMOC was held at the AFEI Net-Centric Operations 
conference in Washington, DC, using the Universal Space 
Network Alaska ground station to access the router during 
two satellite passes. 

Lessons From Tests and Operation 

An Internet router is good for arbitrating fairly between 
nodes competing for access to a link in order to provide 
multiplexed access to connectivity. This is the dominant 
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terrestrial Internet mode of operation. But when you own and 
manage your own computers onboard your own small 
satellite, and you have the power budget and accessibility 
concerns of a small satellite, a coarser-grained scheduling 
paradigm becomes much more attractive. You download data 
fdes from an onboard computer payload, and once it holds 
nothing more of interest you simply turn that computer off 
until it is next needed. Each computer is scheduled dedicated 
access to the downlink, and other engineering design 
decisions fall out from that. (Although scheduling of payload 
on times and access to the multiplexer is timetabled in 
advance, a “soft scheduling” model is used where the 
schedule is uploaded as a textfde to the platform’s onboard 
computer to interpret and follow, and the schedule for future 
events can be updated, altered and uploaded during any pass 
prior to events taking place.) 

The dominant terrestrial Internet mode of operation would 
be more attractive for large shared platforms (ISS, Hubble), 
or for payloads onboard permanently accessible 
geostationary satellites with higher bandwidth links. 

In the terrestrial Internet, immediate end-to-end 
connectivity is important; the ability to reach another 
endpoint in a timely fashion. This is what makes the instant 
clickability of the web and audio and video streaming 
possible. 

For a low-Earth-orbiting small satellite doing store-and- 
download that is not backhauled via connectivity through a 
geostationary transponder to download its images 
immediately after taking them, pass utilization — getting as 
much out of each pass over each ground station and available 
download time — dominates. This desire to download as 
much data as possible, in the case of the UK-DMC imaging 
requirements, led to the development of a custom network 
stack using the rate-based UDP transfer protocol, SSTL’s 
Saratoga, in order to fill the downlink with image files and 
use the ten or so minutes of a pass as effectively as possible. 
The images were downloaded across a single link, the 
downlink, to a ground station, and no further. Saratoga’s 
design lacks congestion control algorithms, making it 
unsuitable for widespread Internet use between any endhosts 
— while the TCP suitable for Internet use would not make 
efficient use of the available pass, and would be more 
effective for arbitrating between multiple competing onboard 
computers using a multiplexing, rather than the scheduling, 
model outlined above. 

The image download model here is more analogous to e.g., 
application-level http proxy caching, where files are cached 
locally to avoid creating bottleneck-constrained long paths, 
and processed at the ground station cache, and then fetched 
on demand by terrestrial users. However, the end-to-end 
connectivity model still applies for real-time commanding 
(done by uploading scheduling files by TCP/IP, and for 
direct access to the onboard router) and for streaming 
telemetry (implemented as broadcast UDP from the satellite 


for the ground station LAN and repeated to select 
destinations via a unicast UDP reflector, but which could 
easily be implemented as multicast traffic.) 

Even if a LEO imaging satellite used a geostationary 
transponder to communicate with a ground station for 
extended periods of time, power and link efficiency concerns 
and the desire to switch between scheduled payloads based 
on need would still encourage the adoption of rate-based 
transfer protocols rather than TCP, given TCP’s well-known 
inefficiencies in adjusting to geostationary delays. 

Adoption of terrestrial network technologies means 
necessary adoption of widespread terrestrial security 
paradigms, which are fortunately well-understood. SSTL’s 
ground station LAN becomes an integral part of SSTL’s 
corporate network, and is now managed in the same way by 
the same people. Cisco PIX firewalls were used to set up a 
Virtual Private Network (VPN) between ground stations. 
Link-level encryption of the UK-DMC satellite link might 
also be considered necessary, but was not done. Future SSTL 
missions are considering link encryption. 

Given the limited pass times and availability of the 
onboard router, it was extremely helpful to have a ground- 
based testbed, combining the sister engineering model of the 
flight router with one of SSTL’s SSDRs (fig. 3). This rack- 
mounted ground-based testbed is connected to a personal 
computer, which emulates the OBC. 

This testbed was constructed after launch for NASA Glenn 
to gain familiarity with the SSTL network environment and 
payloads, and to enable NASA Glenn to determine 
successful and safe configurations for the onboard router that 
would not interfere with SSTL’s primary mission. Working 
configurations were copied to the router in orbit once tested 
and validated on the ground-based testbed. This enabled 
effective use of the limited on-orbit testing time, enabling the 
ability to configure the on-orbit router essentially from 
nothing in few passes. 



Figure 3. — Ground-based testbed. On left: SSTL 
SSDR assembly. On right: router assembly. 
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Problems Encountered 

Technical problems encountered during testing and 
operating the router payload were relatively minor. 

While in the Vandenberg tent, the VMOC operators found 
that they were getting satellite passes finishing a couple of 
minutes earlier than expected — because their Solaris 
workstations were not configured to use the network to query 
time server using Network Time Protocol (NTP) to update 
their local clocks. When operating actual satellites, it is 
helpful to know the actual time. 

The UK-DMC satellite was temporarily unavailable 
between the testing campaign and the demonstration, due to a 
problem encountered by its on-board computer (OBC) 
requiring that computer to be reset. As a knock-on effect, 
SSTL had been rebooting its SSDRs daily to work around a 
problem with their serial driver software in coming out of 
pass-through mode to support the router, so access to the 
router was unavailable until both the OBC and SSDRs had 
been commanded to reboot on subsequent passes. Given 
SSTL’s soft scheduling methodology, rescheduling future 
events to take account of lost time is relatively 
straightforward. 

The OBC IP stack is written in-house by SSTL and 
considered experimental; the OBC can also run AX.25-based 
communications software (and the other DMC satellites do 
so, while their payload computers are IP based). This AX. 25 
fallback use reflects SSTL’s long amateur radio experience 
and heritage. SSTL has moved the UK-DMC OBC back to 
AX.25 while debugging its internal software, removing a 
source of UDP-based telemetry during passes. 

The Universal Space Network Alaska ground station used 
to receive low-rate telemetry during the Vandenberg 
demonstration took some time to become fully operational; it 
was discovered that the high-speed downlink signal was too 
strong for and saturated the Comtech modem in use, 
requiring additional attenuation to be inserted. That 
attenuation was achieved by the Alaska RF chain working 
off right-circular polarisation, while the signal is left-circular 
polarised. Occasional multipath distortion resulting from this 
led to occasional poor link quality during passes over Alaska. 

The General Dynamics VMOC models satellite orbits, 
visibility and availability. However, for a satellite operated 
by a third party, this model turns out to be approximate at 
best, as the GD VMOC is unaware of other parties’ 
conflicting scheduling requirements or of power demands 
onboard the UK-DMC, or of details of imaging capabilities 
or storage limitations. The GD VMOC can only prioritise 
requirements that it is aware of, resolving conflicts between 
and for its own users. The VMOC’s assumptions were not 
always applicable to shared assets over which the VMOC 
does not have absolute control. A later iteration of the GD 
VMOC/SSTL MPS interface handed off more functionality 
to the autonomous SSTL MPS, moving away from hard 


absolute commanding by VMOC to a higher-level softer 
request negotiation model. 

The CLEO Cisco router performed entirely as expected. 

Ongoing Development of CLEO 

Testing of the CLEO router continues only when the UK- 
DMC satellite is not otherwise tasked with its primary 
imaging mission. This testing relies on scheduled passes over 
the USN Alaska ground station to avoid using passes over 
SSTL’s own ground station whose opportunity cost would 
detract from SSTL’s normal operations and from the 
satellite’s primary mission. 

The CLEO Cisco router has been in space for over twenty 
months, and has been tested in orbit for over a year. CLEO 
has been powered up more than forty times for testing during 
passes over ground stations. There is interest in seeing how 
long this commercial, non-hardened computing device using 
non-space-qualified parts will last in low Earth orbit, and 
what total radiation dose it will tolerate. Several passes per 
week used for accessing and configuring the router can be 
accomplished. 

The success of CLEO, showing the use of Cisco’s IOS 
router software in orbit, has led to Cisco Systems taking the 
next step of porting IOS to a space-qualified radiation- 
hardened processor in the PowerPC family: the BAE750. 
This would be used in a fully space-qualified embedded 
router. 

Conclusions 

The UK-DMC satellite demonstrates that handling satellite 
command and telemetry and data delivery based upon the 
Internet Protocol and related commercially-used standards is 
possible and can be successful. 

The CLEO experiment onboard the UK-DMC satellite has 
shown that a commercial off-the-shelf router can be adapted 
to and work in the space environment in low Earth orbit, 
building on commercially-used standards that had already 
been adopted for their benefits. The use of CLEO for mobile 
networking showed that mobile networking is a viable 
technology for networking across disparate and separate 
networks on two continents. 

The use of VMOC with the SSTL mission planning system 
shows that a high-level approach to exchanging data between 
complex systems, building on open standards, can allow 
independently-developed autonomous systems to 
interoperate with beneficial results. 
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